Due to the nature of flash memory in solid state drives (SSDs), data is typically programmed by pages and erased by blocks. A page in an SSD is typically 8-16 kilobytes (KB) in size and a block consists of a large number of pages (e.g., 256 or 512). Thus, a particular physical location in an SSD (e.g., a page) cannot be directly overwritten without overwriting data in pages within the same block, as is possible in a magnetic hard disk drive. As such, address indirection is needed. Conventional data storage device controllers, which manage the Flash memory on the data storage device and interfaces with the host system, use a Logical-to-Physical (L2P) mapping system known as logical block addressing (LBA) that is part of the Flash translation layer (FTL). When new data comes in replacing older data already written, the data storage device controller causes the new data to be written in a new location (as the data storage device cannot directly overwrite the old data) and update the logical mapping to point to the new physical location. At this juncture, the old physical location no longer holds valid data. As such, the old physical location will eventually need to be erased before it can be written again.
Conventionally, a large L2P map table maps logical entries to physical address locations on an SSD. This large L2P map table is usually saved in small sections as writes come in. For example, if random writing occurs, although the system may have to update only one entry, it may nonetheless have to save the entire table or a portion thereof, including entries that have not been updated, which is inherently inefficient.
FIG. 1 shows aspects of a conventional Logical Block Addressing (LBA) scheme for data storage devices. As shown therein, a map table 104 contains one entry for every logical block 102 defined for the data storage device's Flash memory 106. For example, a 64 GB data storage device that supports 512 byte logical blocks may present itself to the host as having 125,000.000 logical blocks. One entry in the map table 104 contains the current location of each of the 125,000 logical blocks in the Flash memory 106. In a conventional data storage device, a Flash page holds an integer number of logical blocks (i.e., a logical block does not span across Flash pages). In this conventional example, an 8 KB Flash page would hold 16 logical blocks (of size 512 bytes). Therefore, each entry in the logical-to-physical map table 104 contains a field 108 identifying the die on which the LBA is stored, a field 110 identifying the flash block on which the LBA is stored, another field 112 identifying the flash page within the flash block and a field 114 identifying the offset within the flash page that identifies where the LBA data begins in the identified Flash page. The large size of the map table 104 prevents the table from being held inside the SSD controller. Conventionally, the large map table 104 is held in an external DRAM connected to the SSD controller. As the map table 104 is stored in volatile DRAM, it must be restored when the SSD powers up, which can take a long time, due to the large size of the table.
When a logical block is written, the corresponding entry in the map table 104 is updated to reflect the new location of the logical block. When a logical block is read, the corresponding entry in the map table 104 is read to determine the location in Flash memory to be read. A read is then performed to the Flash page specified in the corresponding entry in the map table 104. When the read data is available for the Flash page, the data at the offset specified by the Map Entry is transferred from the Flash device to the host. When a logical block is written, the Flash memory holding the “old” version of the data becomes “garbage” (i.e., data that is no longer valid). It is to be noted that when a logical block is written, the Flash memory will initially contain at least two versions of the logical block; namely, the valid, most recently written version (pointed to by the map table 104) and at least one other, older version thereof that is stale and is no longer pointed to by any entry in the map table 104. These “stale” entries are referred to as garbage, which occupies space that must be accounted for, collected, erased and made available for future use. This process is known as “garbage collection”.
An atomic command is one in which the command is either performed completely or not at all. Since a power cycle is often the cause of some commands not being able to finish, any atomic write command must take into account the power cycle issue. Conventional methods of implementing atomic write commands in flash-based data storage devices do not allow for efficient detection of incompletely-processed atomic write commands, efficient garbage collection of blocks with in-process atomic writes and meta data or rely on duplicating the atomic write data in buffers, thereby increasing write amplification, system complexity and generating free space accounting issues.